As you may already realize, many of my editorials spring from various issues that my team and I encounter when building software for our clients. Most of my editorials are post-mortems on our projects or thoughts spawned by the project experience. This time, I'm going to try something a bit different. I'm going to do a “pre-mortem.” What I mean by that is that I'm going to write about a project from its inception. It's likely that I'll continue writing about this project as it progresses. Real world work tends to provide fertile material for my editorials and I expect this project to be no different.

The Project

Dear reader, you're about to embark on another journey into Application Conversion Land. Yes, we're doing another conversion project. This time we're taking a 20-year-old Visual FoxPro project and converting it into a modern architecture using WPF, C#, and SQL Server.

If you follow my editorials, you'll recall that we've been involved in several conversion projects. My Nov/Dev 2017 editorial “Lessons Learned from a Second Trip Around the Block” discussed a number of lessons we learned on a long-term conversion project. These lessons are at the forefront of every member's mind as we embark on this new adventure.

The Team

The most important aspect of a successful software project is the team of people that build the software. By Dash Point Software (my company) standards, we have a reasonably large development team for this project. The team consists of seven software engineers assisted by other team members who handle roles such as project management, testing, and database management.

A critical aspect of building this team is the relationships among the different members. I chose “known quantities.” All of the developers had worked on one or more projects together, which helps cut down on the sometimes-slow process of learning how to work with new people and how their skills fit into the team. There's another unique aspect to this familiarity: Some of us were on board 20 years ago when the initial project was created. That longevity is important because it provides continuity and a deep understanding of our problem domain.

The Process

This project is being developed by combining several agile software development techniques, principles, and processes. Agile software practitioners will tell you that there's no one way to manage an agile software development, and I believe that to be true. For this project, I chose to employ the following concepts: pair programming, unit and integration tests, daily standups, and Kanban management.

Pair Programming

One of the most valuable agile techniques is the concept of pair programming. I find this technique valuable because it helps spread knowledge from one team member to another. I've been using Visual Studio and C# from Day One and even so, I still learn new tools and techniques from other developers. We don't practice full time pair programming because our teams are geographically distributed, but we try to emphasize the pairing off for a few hours of every week.

Unit and Integration Tests

Unit tests and integration tests serve a very important role in our application process. These tests are long-term investments in the stability and maintainability of our software. We're building this app to last another 20 years and the automated tests serve to insure the long-term viability of our project.

Daily Standups

When building software with a team of this size, it's important to touch base on a frequent basis. For this, we have daily standups. The goal is to keep other developers informed about what's being worked on by other developers and, most importantly, for the team to communicate any blocking issues they may have.

Kanban Management

We're using a Kanban board to manage all tasks that are under way at any given time. We're starting to build a backlog, insuring that developers have a constant set of items to work on. We're not following Kanban 100%; we're using only the tools that work for us.

The Tools

“I can fix it. My dad is a TV repairman. He has an awesome set of tools.” No truer words have been spoken than those of the stoner-philosopher Jeff Spicoli in the classic film “Fast Times at Ridgemont High.” Well, we at Dash Point have an awesome set of tools too. Over the years, we've curated a great set of software development tools and utilities. Here are a two we've deployed:

  • Slack: We use Slack as mechanism for communicating among all of the software team members. We use Slack to keep a persistent record of questions, concepts, ideas, techniques, and other project information that needs to be shared among members of the team. This tool helps prevent the e-mail barrage that generally happens with software projects.
  • ReSharper and ReSharper Templates: Our internal framework has a set of standardized ways to perform various tasks. We've created a set of templates to automate the basic bootstrapping of these tasks. This removes some of the mundane tasks (boring) that accompany all software projects

Other tools we use are Jira (Kanban Management), Google Sheets (task management overview), Jenkins (continuous integration server), and SQL Prompt (a SQL standardization and formatting tool).

Early Lessons

A few weeks ago, we convened the first meeting; the entire team was present in the same geographic location. The purpose of this meeting was to discuss project goals and software development processes, and to demonstrate how to use the current set of tools and framework code. I can say with zero hesitation that this is one of the best teams I've had the privilege to work with. It took no time for the team to throw out constructive criticism, new ideas, techniques for making our process work better, and especially important, the desire to “do this right” from the start. I really look forward to seeing how we perform over the long haul. From what I'm seeing, we are off to a great start.